standards

This question already has an answer here: Is it wrong to change a block element to inline with CSS if it contains another block element? 9 answers The W3C Validator tells me I can't put block-level elements inside inline elements. Makes sense... but what if I'm using CSS to change that block-level element into an inline element? And what if I'm using CSS to convert an inline element into a block-level element (when inside another inline element)? The Validator doesn't pick up on this obviously, but is it wrong? (I'm not actually doing this, I'm just wondering about best-practice) An element

The documentation of std::numeric_limits<T> says it should not be specialized for non-fundamental types. What about number-like user-defined types? If I define my own type T which represents a numeric value and overloads numeric operators, and for which the information represented by numeric_limits makes sense -- will anything break if I specialize numeric_limits for that type? Short answer: Go ahead, nothing bad will happen. Long answer: The C++ standard extensively protects the ::std namespace in C++11 17.6.4.2.1, but specifically allows your case in paragraphs 1 and 2: The behavior of a C++

This SO question sparked a discussion about std::generate and the guarantees made by the standard. In particular, can you use function objects with internal state and rely on generate(it1, it2, gen) to call gen() , store the result in *it , call gen() again, store in *(it + 1) etc., or can it start at the back, for example? The standard (n3337, §25.3.7/1) says this: Effects: The first algorithm invokes the function object gen and assigns the return value of gen through all the iterators in the range [first,last) . The second algorithm invokes the function object gen and assigns the return

What is an Anonymous Object exactly? Does C++ support/have Anonymous Objects? The C++ standard does not define the term "anonymous object", but it stands to reason that one might sanely use the term to describe any object that has no name: Temporaries: f(T()); Unnamed function parameters: void func(int, int, int); What I wouldn't count is dynamically-allocated objects: Technically speaking, an "object" is any region of storage [1.8/1 in 2003], which would include the X bytes making up the integer dynamically-allocated by new int; . In int* ptr = new int; the pointer (itself an object too, don

This is a question in two parts, the first is the most important and concerns now: Are you following the design and evolution of C++11? What blogs, newsgroups, committee papers, and other resources do you follow? Even where you're not using any new features, how have they affected your current choices? What new features are you using now, either in production or otherwise? The second part is a follow-up, concerning the new standard once it is final: Do you expect to use it immediately? What are you doing to prepare for C++11, other than as listed for the previous questions? Obviously, compiler

Is anybody working on a jQuery.closest() equivalent in the DOM api? Looks like the Selectors Level 2 draft adds matches() equivalent to jQuery.is() , so native closest should be much easier to write. Has adding closest() to Selectors come up? Element.closest() its support Implementing such function with Element.matches() seems not optimal in terms of performance, cause apparently matches() will make a call to querySelectorAll() every time you test a parent, while only one call is sufficient for the job. Here's a polyfill for closest() on MDN. Note a single call to querySelectorAll() if (window

I've been arguing with my coworkers about Pascal casing (upper camel case) vs. lower CamelCasing . They are used to lower camel casing for everything from table names in SQL databases to property naming in C# code but I like Pascal casing better, lower camel casing for variables and Pascal casing for properties: string firstName; public string FirstName { ... } But they are used to this: string _firstname; public string firstName { ... } I try to keep up with their "standard" so the code looks the same but I just don't like it. I've seen that at least the .NET framework uses this convention

I am asking this questions because we will develop an application that is supposed to share cross origin data via javascript. One possible solution seems JSONP as it uses SCRIPT tags pull data from other domains. However, I would like to avoid the situation that we implement our awesome code on the assumption that the SCRIPT tag is not subject to sop and at some point browsers prohibit this functionality. Can anybody shed some light on what is the reason for the SCRIPT tag to allow cross domain requests? I suppose this draft titled "Principles of the Same-Origin Policy" explains (albeit