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/
