Posted by NewsGrail 2 years 43 weeks ago
I ran the test once and got a score of 4.5, one of the warnings was about missing inputmode attributes. So, I added the inputmodes and then re-ran the test, this time scoring lower than I did the first time. The reason was that adding inputmode in a couple of places had increased the pagesize and the validator had penalised me for it.
Edit: Another bug in error text:
FAIL near line 1 column 8236
Attribute "hef" must be declared for element type "a".FAIL near line 1 column 8672
Attribute "hef" must be declared for element type "a".FAIL near line 1 column 12677
Open quote is expected for attribute "{1}" associated with an element type "href".
Presumably "{1}" should have been populated with a value.
On a related note, a lot of the feedback I've read here relates to the error messages being confusing and it is often difficult to work out what they refer to. Even if {1} were populated I don't think I could guess what the error is. The "Attribute "hef" must be declared for element type "a"." reads as almost the opposite of what it means.
On a lesser related note, the validator does not appear to take gzipping into account which has a profound effect on the pagesize and eventual scoring. There's an article on your site somewhere about how gzipping is increasingly widespread among mobile devices with a tutorial about how to use it, so it seems fair that this should be considered.
Posted by ruadhan 2 years ago
Mobile Champion
I think this is the expected behaviour - the page size of the 'correct' page was larger than when it contained errors, so why wouldn't ready.mobi flag an error when the larger correct page starts to get too big?
I understand the difficulty people have with the error messages - at first glance they are misleading, but they are difficult for us to change since they come directly from the validation component of ready.mobi.
In this case, the message should have been interpreted as "You must define an attribute 'hef' in your document DTD before you can use it in your document". And in this case, the real problem was that you specified hef instead of href.
We link to mobiForge articles explaining the most common of these error messages when they occur in the ready.mobi results - we display a 'help me fix it' link whenever ready.mobi finds an error in your page. The most common validation error messages are explained here.
Probably {1} was occurring somewhere in your markup rather than being a ready.mobi variable that was not substituted (internally, ready.mobi does not use a substitution system with {...} syntax).
I need to check up on the gzip issue, but my feeling is that the unzipped size should be taken into account since it will be the unzipped size that is important when the memory limitations of the user device are the issue. Of course when considering how much data is actually downloaded over the network then we should be looking at the gzipped size...
Cheers for the feedback!
Ruadhan O'DonoghuedotMobi
Posted by NewsGrail 2 years ago
I understand where you're coming from and I think it is expected behaviour by default, but you've made changes specifically because the test told you to do so and you are then penalised for doing so, the result is contrary.
Because the score drops when making the accessibility changes, the implication is that adding accessibility is worse than just leaving it out entirely and keeping the page smaller. I assumed that accessibility should take priority over bandwidth since that is the attitude for broader web development, but on reflection that may not be true for mobile development?
Since compression is extremely easy and extremely beneficial (more so even to mobiles than desktops), perhaps it should be one of the warning/penalty attributes if it can't be taken into account by default. The description for failing the page size test only mentions bandwidth charges and loading time, not memory limitations so it would be a helpful note to add if that's a consideration as well. It hadn't occurred to me that would be a problem.
Thanks for the help.
NewsGrail Mobile, the collaborative social news network.Posted by ruadhan 2 years ago
Mobile Champion
I understand too where you're coming from, but your argument sort of reads that because you made one error and fixed it, then you should be exempt from other tests. Each ready.mobi test is independent, and if the markup got larger when you fixed something then that is the markup that ready.mobi will check the next time you check your page, independently of any previous check that you ran. Ready.mobi can't second guess what your markup might look like after you have fixed something...
In terms of accessibility, large pages are still slow and expensive to download, and some devices have low memory limits. Page size is important in these cases.
Good point - we'll review this!
Ruadhan O'DonoghuedotMobi