Going back to the original “tangent”… Philip did raise a valid point. A site should validate and validation is also a great way to catch the “silly mistakes” we introduce form copying/pasting, typing etc.
However, in this age of building sites with bootstrap, jquery plugins we find to help resolve a problem, etc. we introduce (especially css) code into our projects that we did not write. As was so amply demonstrated in this case, many don’t pass validation. I, for one, don’t feel comfortable “correcting” these errors as i(in the case of bootstrap) I’m just coming to grips with responsive site building and don’t wish to modify the underlying “structure” (which I only sort of understand) in case I cause the whole house to fall. I just sort of assume the bootstrap people who coded their css know a lot more than me about css (however, it is surprising that their’s doesn’t validate). What are other’s thoughts/solutions on/for this? > Going back to the original problem for a second, the fish in question is > making the links on Bob's site work on touch-enabled devices. > > To catch the fish, I opened the provided URL in Chrome on my laptop with the > DOM inspector open. The links worked as expected by default, but when I > enabled device emulation to mimic the latest Nexus (a recent smartphone with > an associated OS and Chrome variant as its default browser), I noticed the > behaviour Bob was talking about. Seeing as the DOM inspector and the viewport > showed the link as having been successfully rendered and exhibiting expected > default behaviour in at least one instance, I suspected JavaScript: Bob had > described the mechanism revealing the links as dependent on hover or touch – > hovering has a corresponding CSS state but changing style on touch > necessitates scripting. After opening the DOM inspector's 'sources' panel, > which deals with JavaScript debugging, I toggled 'pause' [1], which stops > JavaScript execution and reveals the line of code which is attempting to > execute. This revealed the code block in question, which handles the > application of a 'hover' class on touch. But the code was also preventing the > default behaviour of that event, which would be to follow the link as > expected. Preventing default behaviour is often desirable when JavaScript > enhancements replace default functionality, but this isn't one of those > cases: we want to apply scripted behaviour regardless of defaults. So by > removing the call to `preventDefault`, we let the event take its natural > course and expectations are met. > > So 'validate your markup', as much as it may be good advice, wouldn't have > caught this particular fish. In fact, I might assert that 'validate your > markup' hasn't taught us anything with regards to this particular problem. > The reason people come to this list is usually to seek human insight and > communal effort on given problems, which code parsers are unable to give. > Conversely, actually reading about Bob's problem, visiting the URL and trying > to replicate the behaviour he described proved to be a really good first step > to solving the problem. > > [1]https://developer.chrome.com/devtools/docs/javascript-debugging#sources-panel > > On 6 Oct 2014 18:07, "Karl DeSaulniers" <k...@designdrumm.com> wrote: > So in other words. Philip is teaching to fish. Not just giving you a fish. > > Kudos Philip! > > Best, > Karl > > Sent from losPhone > > > On Oct 6, 2014, at 5:07 AM, Philip Taylor <p.tay...@rhul.ac.uk> wrote: > > > > > > > > > > Barney Carroll wrote: > > > >> CSS discuss often reminds me of my doctor, to whom I'll often go with > >> queries about an acute injury and come away with advice to stop smoking > >> – wise & well-intentioned, but somewhat short of the assumed benefits in > >> seeking expert advice for a specific problem. > > > > But your doctor knows that advising you how to treat an acute pain in your > > finger caused by an ingrowing nail is unlikely to result in any overall > > improvement in your condition while you have 252 co-morbities in your arm > > alone, and four affecting your whole body : > > > > > > http://jigsaw.w3.org/css-validator/validator?uri=http://www.dlp-distribution.fr/ > > Sorry! We found the following errors (252) > > > > http://validator.w3.org/check?uri=http://www.dlp-distribution.fr/ ( > > errors, now now fixed). > > > > It should be a /sine qua non/ to ensure that a given web page validates for > > both HTML and CSS before asking for help; if Mr Schwartz removes the > > `e.preventDefault()` invocation on line 22, his page /may/ work as intended > > on one specific smartphone or tablet today, but it may do something > > completely unexpected on another device, or tomorrow, or if the wind blows > > in a different direction, because whilst it is possible to predict the > > behaviour of valid code with reasonably (but by no means absolute) > > certainty, it is completely impossible to predict the behaviour of invalid > > code in any meaningful way at all. > > > > Philip Taylor > > ______________________________________________________________________ > > css-discuss [css-d@lists.css-discuss.org] > > http://www.css-discuss.org/mailman/listinfo/css-d > > List wiki/FAQ -- http://css-discuss.incutio.com/ > > List policies -- http://css-discuss.org/policies.html > > Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ ______________________________________________________________________ css-discuss [css-d@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
