Bootstrap's pragmatic approach deems validity not to be a concern: https://github.com/twbs/bootstrap/issues/6398
In theory, total W3 compliance will make your code behave completely predictably in any environment you care to mention. In practice, popular browsers have deviated from the spec time and time again, with the result of invalid code sometimes being the only way of achieving certain effects in certain browsers. The specifics in Bootstrap's CSS are legacy IE hacks and vendor-prefixed CSS3. Depending on the scope of your expectations, there are often times when something will work in practice but not in theory. A dogmatic purist approach will say that expectations must be revised to match the theory, but I'll always try and find a solution regardless. It's interesting to note that popular frameworks of this ilk (HTML5 boilerplate being another) often fail W3 validation. It's also interesting to tally up the number of times you're faced with tricky problems with regards to web development and code expectations, and W3 validity resolves them. On 7 Oct 2014 07:48, "Bob Schwartz" <b...@fotografics.it> wrote: > 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/
