CSS Cascade and Inheritance spec defines the so called 'Override origin' for style sheets that links to DocumentCSS interface (from the DOM Level 2 spec from the year 2000). This seems to be the only mention of this interface on the W3C site (except of short conversation in the www-dom mailing list from 2008). The DOM Level 2 spec has the following text about it:
The expectation is that an instance of the DocumentCSS interface can be obtained by using binding-specific casting methods on an instance of the Document interface.
Is this mechanism implemented anywhere? Is it possible to play with these 'override styles' and to see the DocumentCSS interface in action?
Sorta exists in WebKit (via KHTML) but not really, because the implementation just returns null.
And that just-return-null implementation ended up in Chrome too but was subsequently removed.
Also, as a comment above notes, a Firefox feature request has been open for it for 10+ years.
As far as Edge, there’s no indication it’s been implemented there yet either.
So it seems the answer is, it’s never actually been supported anywhere. Maybe somewhere in the CSS Houdini plans there’s something that will provide the same functionality?
Related
I am trying to gain knowledge of CSS3 so I know user interface module, it provides a bunch of properties in that has resize property, but I dont know why it has resize property that allow user to change size of elements.In addition to that I have no idea of what is purpose of user interface module is used for.
so I hope someone can answer this to me.
very thanks.
CSS Basic User Interface Module Level 3 (CSS3 UI) by Tantek Çelik and Florian Rivoal (editors), W3C candidate recommendation of 2 March 2017, has the following to say:
The purpose of this specification is to achieve the following objectives: extend the user interface features in CSS2.1; provide additional CSS mechanisms to augment or replace other dynamic presentation related features in HTML; introduce directional navigation properties to assist in the construction of user interfaces which make use of a directional navigation model.
Please note that a styling property does not become instantly available in all browsers just because the W3C published a candidate recommendation. You should check that you can actually use the properties described in the document. Can I Use comes to mind.
As far as I can tell the specification provides some nice tools for styling interactive HTML documents, such as web-based applications. For example, it allows drawing outlines around objects, modifying the shape of the mouse cursor and other such goodies. Whether you want to use them or not, and indeed whether you can use them or not depends on your design and your target audience.
As to "why it has resize property": because it exists in some browsers. In this case the W3C just documents and standardizes an already existing technology.
This "question" has been asked before I've seen, but none of those existing answers really address the question, nor provide resources that are exhaustive in themselves. I am looking for a single resource that I can import into code easily, not have to write a web scraper to expand every possible link and then scrape secondary and tertiary pages for property values.
Examples of links that are useless: (or borderline so)
http://meiert.com/en/indices/css-properties/
for other useless links, check the prior questions, my reputation won't let me post more than 2 links as examples.
Almost ok(ish)
https://www.w3.org/TR/CSS21/propidx.html (except that it is a small fragment of what is possible with css3 and links elsewhere for other properties, and one has to expand the <...> refs to find the actual values for many properties as well).
Ideally something like in the mozilla headers/code might work, requiring a minimal processing, or just a flat table if someone knows where it is would be great.
Hopefully this doesn't get closed as off topic, because the list of property keys and values is of paramount importance for programmers. Otherwise how would one know what all the valid values are? Anyway, I don't think its the kind of question to attract spam, esp as I've done some in depth googling.
This is for inclusion in separate library, not to just write css myself.
...because the list of property keys and values is of paramount importance for programmers. Otherwise how would one know what all the valid values are?
One very easy way to find out the available properties and values is to play with the browser dev tools.
Open the dev tools in your favourite browser. Inspect any element you like from the page you're on, and you should get the HTML shown on the left, with the CSS and other properties of the current element on the right. From here you can explore the available styles, and see their effect in real-time.
The "Computed" styles will show you all the styles that are available and their current settings. The main styles tab will allow you to add new styles or change existing ones. In most browsers, you can use the cursor keys here to explore the values that are available for any given CSS property, and also the properties that are available for the current element. Making changes here will update the page immediately. This is a great way to learn the kinds of things you're looking for.
I think I found something workable, hopefully this helps others too. Basically the place to look is in the opensource webkit code at the CSSPropertyNames.in and CSSValueKeywords.in files. I'm looking at version 7601.3.8 on Apple right now. A user can extract what they need without too much work, though I may just write an easy to use/shareable lib for others.
http://opensource.apple.com/source/WebCore/WebCore-7601.3.8/css/CSSPropertyNames.in
http://opensource.apple.com/source/WebCore/WebCore-7601.3.8/css/CSSValueKeywords.in
7601.3.8 is up to date as of 2015, according to the changelog. It may not have absolutely everything, but I think it should work.
Actually the list I included here is not exhaustive either. The webkit .in files cop out and just list a bunch of values under CSS_PROP_OTHER.
I am having issues with Chrome throwing element stale, element not click able other element would receive click. My question more so has to do with pageFactory framework.
Given that chromedriver has these issues I would need to rewrite the selectors with offsets and other functionality to make it able to be click able correctly.
Should I make new xxxxPage.class's specifically for chrome? Or should I just incorporate all the chrome fixes into the current xxxxPage class, knowing that it will most likely work in firefox?
Or I can make a copy of the "SignIn" function for example with chrome fixes.
Basically what is the best way of keeping your final test code clean, with these changes?
Thanks
From my perspective the page object should describe the page elements and not should be depends to the concrete driver implementation. I suggest to implement the helper common class that contains some common methods and then the specific classes that contains the specific implementation per browser. Then in your page object you will call the one common function which will call the required to the driver class/method. In other words you will encapsulate the specific driver behaviour in the specific classes and the common class will decide what specific class will called.
I would like to know if CSS3 is an official W3C standard or just something like "CR" (Candidate Recommendation)?
CSS3 is described as the next generation of the CSS styling language (just like HTML5 is the next generation of HTML), building upon the foundation set by CSS2.1, the de jure CSS level 2 spec. It is still in active development and has not entirely been finalized yet.
In fact, CSS3 will probably never reach a "final" state in the sense of the word, as new modules are being added all the time. This is because starting from level 3, CSS itself has been modularized, such that each module can be developed independently of the rest (although related modules may be developed in tandem). This allows not just for existing modules to be leveled independently, but new modules to be created at any time, either defining completely new sets of features, or extending from existing CSS2.1 features.
Modules that are based on existing sections of the CSS2.1 spec start off at level 3, while modules that are entirely new to CSS as a whole start from level 1. Now, although "level 4" would seem to imply that there is a CSS4 coming, just as how "level 3" is often used to refer to CSS3, one of the CSSWG members has published a blog post talking about the term "CSS4" saying that is not the case:
THERE IS NO SUCH THING AS CSS4
There has never been a CSS4. There will never be a CSS4. CSS4 is not a thing that exists.
The term "CSS3" refers to everything published after CSS 2.1.
CSS is on its last version as a language as a whole, so it would be appropriate to just drop the number entirely and refer to everything from now on as just "CSS".
While trying to finish CSS 2.1, we (the CSSWG) realized that big monolithic "versions" weren't any good. They were difficult to maintain, and slow to develop.
Instead, we decided to split up the CSS language into a bunch of independent modules. Each module can level up independently, and contains only a smallish set of features, so it's harder for a large set of features to be slowed down by a single stubborn feature.
Some of our modules start out at level 3, if they extend something from CSS2.1. Others start out at level 1, if they're something new (for example, Flexbox). However, the level that a module is at has no correlation with what version of CSS it's in. They're all CSS3 (or just CSS), regardless of what level they're at.
Because each module is developed independently, as of 2012, only certain modules have reached or surpassed the Candidate Recommendation (CR) stage. Notable ones include:
Media Queries
Namespaces
Colors
Selectors
Backgrounds and Borders
Image Values and Replaced Content
Multi-column Layout
Values and Units
Most of the dozens of other modules are still in draft, and it may take a few months or years before they reach CR, PR or REC. And as mentioned, more are being added all the time, and these will be leveled in their own pace as well.
For information on the status of development of CSS, see the following pages:
CSS Current Status - W3C. Specifications listed under Standards have been standardized as W3C Recommendations. This is maintained by W3C; the specifications themselves, however, are maintained by the CSS Working Group, who are directly involved in the development of CSS.
CSS Current Work. There's a table of specifications here so you can see at a glance how mature each module is in development. This page is maintained by the CSS Working Group.
W3C CSS WG Note. This page describes the development process of the CSS standard. It mentions the term "level", which is used to describe each revision of the CSS standard rather than the term "version":
2. CSS Levels
Cascading Style Sheets does not have versions in the traditional sense; instead it has levels. Each level of CSS builds on the previous, refining definitions and adding features. The feature set of each higher level is a superset of any lower level, and the behavior allowed for a given feature in a higher level is a subset of that allowed in the lower levels. A user agent conforming to a higher level of CSS is thus also conformant to all lower levels.
Additionally, given this modularization of CSS, and the completion and standardization of some modules, work has begun on level 4 of these modules, for example Backgrounds and Borders, and Selectors. However, since these modules have just started, don't expect vendors to start supporting these modules for at least another year. As mentioned above, while these modules are progressing to level 4, they aren't officially defined or versioned as "CSS4".
No, CSS3 is a collective name for a W3C activity of developing CSS. W3C isn’t really a standards body at all; it issues recommendations, and only a few of the areas of CSS3 activity have resulted in recommendations so far. Most of the areas have produced working drafts, which carry the following boilerplate text: “This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.”
I’m wondering why no web browser supports the XInclude standard for XHTML.
This standard exists for almost five years, and I think it would be very useful for the web.
For example, you could XInclude the static parts of your web site, such that the browser will only need to download the part which have changed when the user is browsing the site. Moreover (but I may be wrong) this does not seem to be very difficult to support, in comparison to standards like SVG or MathML.
(sorry for this question without real answer, I will not mind if it is closed)
There is an old open bug on the Mozilla bug tracker asking for XInclude support with a patch in which some problems are discussed:
a satisfactory XInclude implementation requires XPath, XPointer, xml:id and other specs to be implemented first,
most of the time XInclude can be simulated by the document() XSLT function,
loops must be detected and this is hard to do,
it is not well understood how the DOM changes made by XInclude's documents should be encapsulated into events and propagated.