I heard of shadow DOM which seems to solve the problem of encapsulation in web widget development. DOM and CSS rules get encapsulated which is good for maintenance. But then isn't this what iframes are for? What problems are there with iframes that made it necessary for W3C to come up with Shadow DOM or HTML5 Web Components?
Today, iframes are commonly used to assure separate scope and styling. Examples include Google's map and YouTube videos.
However, iframes are designed to embed another full document within the current HTML document. This means accessing values in a given DOM element in an iframe from the parent document is a hassle by design. The DOM elements are in a completely separate context, so you need to traverse the iframe’s DOM to access the values you’re looking for. Contrast this with web components which offer an elegant way to expose a clean API for accessing the values of custom elements.
Imagine creating a page using a set of 5 iframes that each contain one component. Each component would need a separate URL to host the iframe’s content. The resulting markup would be littered with iframe tags, yielding markup with low semantic meaning that is also clunky to read and manage. In contrast, web components support declaring rich semantic tags for each component. These tags operate as first class citizens in HTML. This aids the reader (in other words, the maintenance developer).
In summary, while both iframes and the shadow DOM provide encapsulation, only the shadow DOM was designed for use with web components and thus avoids the excessive separation, setup overhead, and clunky markup that occurs with iframes.
iframes are use as just encapsulation objects...
with the exception of SVG (more on that later), today’s Web platform
offers only one built-in mechanism to isolate one chunk of code from
another — and it ain’t pretty. Yup, I am talking about iframes. For
most encapsulation needs, frames are too heavy and restrictive.
Shadow DOM allows you to provide better and easier encapsulation, by creating another clone of the DOM or part of it.
For example imagine you build a widget (as I have) that is used across websites.
You widget might be affected by the css on the page and look horrible, whereas with Shadow DOM it will not :)
Here is an excellent article on the topic:
What The Heck is Shadow DOM/
Related
I've been using SVGs for a multitude of things and I was able to get the exact result I was looking for. This got me wondering why we can't build entire websites with them...
I don't mean like replace index.html with index.svg. More like having the basic HTML framework (for meta tags, styelsheets, scripts, etc.) and then giving <body> a single inline <svg> child where everything else happens. (text, layout, scaling, etc.)
My initial assumptions are that the website will fall short when it comes to form functionality, SEO, and accessibility. But then again if those can somehow be circumvented, then powerful SVG features can be used to render lightweight graphical effects that can effectively scale to any device dimensions.
Has this been attempted before and what are the potential pitfalls of "replacing" HTML with SVG? Should form functionality, SEO, and accessibility be a valid concern?
Maybe it is time to answer this question again. Contributions and edits are welcome.
Accessibility
SVG content is visual content. That in itself poses restrictions on accessibility. Nonetheless, the upcoming SVG2 spec has a paragraph on ARIA attributes that tries to give at least a bit of assistance. If you look more closely, you will find that for example a graphics primitive will get a default aria-role="graphics-symbol", which is not really helpful.
Whether screen readers implement any of this I don't know.
SVG gives you the opportunity to add <title> and <desc> tags anywhere. But the standard semantics that HTML5 offers through tags are lost. No header, no sections, no TOC or navigation. Try to imagine what the Firefox Reader View could make out of such a page: nothing.
Even linking to partial content of a page is difficult. While the spec is there, the semantic remains constricted: do you really want to highlight a link target by scaling it up to cover the whole viewport?
SEO in the end is just a specialized aspect of accessibility. Having an HTML <header> segment, a few things might be possible. Maybe someone else can comment on what Google implements.
Responsiveness
Problems start with the current inability of automatically line-wrapping text. Layout facilities are still a future project without working implementations. (While Firefox knows CSS inline-size, it is only implemented for HTML and does not work in SVG.)
CSS has put a lot of effort into providing layout mechanisms like flex and grid layout. In SVG, you lose all these techniques for reordering content in favor of simple automatic scaling.
Interaction
Text input is a solvable problem. You can use HTML inputs wrapped in a <foreignObject> tag, or you can build text input widgets from scratch by capturing keyboard input into a <text> element.
For most other forms of user input SVG might even be the superior platform. For example, clicking on/touching something to mark it and dragging it around/swiping it turn out to be only two aspects of basically the same interaction.
Especially Web components are the perfect complement to SVG for building interactive widgets. (Despite you still have to go through polyfills for compatibility with Firefox.)
Form submission
While HTML form submission for initiating HTTP requests might be absent, the advent of single-page apps has shown that it is possible to employ XHR requests instead.
Conclusion
If your content depends on or benefits from the standard semantics HTML5 offers, SVG is clearly not appropriate.
If you need to change the layout of your page in a responsive way, SVG will not be helpful.
SVG gives a lot of additional possibilities for creative, visually-oriented user interactions. As long as you find fallback solutions for visually-impaired users, your page will gain from it.
Overall, SVG gives you creative possibilities for specialized areas and widgets on your page, but falls short on the basic semantic questions a web page has to answer: How does your page relate to other resources on the web? What on your page is content, what is meta information, what is decoration?
The best of both worlds is to be gained by using a mix-and-match approach: structure your page with HTML, decorate it with SVG graphics, and build interactive/animated widgets with SVG and maybe Web Components.
You can build an entire website with SVG. I do it all the time, using Adobe Illustrator to create the pages.
You can go to my site, ozake.com to see a nice example. Even that is pretty basic compared to what is possible.
At first I did it all by hand, but the repetitive parts were annoying so I built a tool called Svija (svija.love, also SVG only).
Essentially you just put an SVG inside of the html body tag.
There are a few things to be aware of:
Microsoft browsers need exact pixel dimensions to be specified or the SVG will be drawn at the wrong size.
The Safari browser does not smoothly scale fonts (see my answer on this page). The consequence is that if you have two adjacent text blocks the space between them will vary randomly if the SVG size varies.
If you want to have several SVG's (one for the page, one for the footer, one for a menu, and one for a special event, for example), you need to be careful that the internal ID's are different.
Otherwise, a color style from the second SVG could be applied to the first SVG, with unpredictable results.
You will probably need to update the font style definitions inside the SVG's to make them work with web fonts. I use both Google Fonts and uploaded WOFF's.
You can make forms as a separate HTML layer based on the Adobe Illustrator system of coordinates. I just build the form in Illustrator, then copy the location and size of each element into absolutely-positioned HTML elements.
It's easier to build separate SVG's for repetitive elements, as I alluded to above. Rather than having to copy a footer to each SVG, just make the footer a separate SVG that's draw on top of the main page.
I built Svija in part to make sure that each SVG has unique internal ID's and to handle the font naming conversion.
You can link to external fonts and images as you would in HTML.
You can animate anything you want using GSAP.
The site is listed normally by Google, but the text will be in the order that it appears in the SVG. You need to pay attention in constructing the SVG if this is a priority.
To handle accessibility, I put the page text in a separate DIV before the SVG. Theoretically, a page reader should read the text inside an inline SVG but I have been unable to find out if this is the case.
I don't want to come across as trying to push my project. It's totally possible to do it all by hand.
I wonder if there is a working way (compliant with most browsers) to show other pages inside a page which belongs to the same domain - I just learned IFRAMES do not allow this- they can only be used to show the content from external sites - right?
Dave
- they can only be used to show the content from external sites - right?
No. There is no restriction on the src attribute of <iframe>s (living standard - HTML 4).
If you're not particularly fond of how the current HTML standard offers information, have a look at MDN's page on <iframe>s - some find its format friendlier.
The main difference between <iframe> and any alternative is that the <iframe> acts like an independent page (it doesn't share resources with its parent document), while fragment / component / template loading is about creating placeholders in a document where contents from another file on the same server will be placed at parse time (so all scripts/styles in parent will apply to the fragment and any such resources loaded by fragment will also affect the parent).
Fragments / components / templates are now only possible through the use of libraries (most popular being jQuery's .load()) but will probably be possible as part of HTML once HTML Components will become living standard.
While some might feel I should have mentioned Shadow DOM here, it is only a special case of HTML Components, which encapsulates its styles and scripts so they do not apply outside the component and also provides a few handy methods to do it (:host, :host() and :host-context()).
Currently, Shadow DOM is a working draft and using it cross browser is only possible with webcomponents.js.
I'm tasked with taking a website and making it so that the AInspector Sidebar evaluates to at least no WAI ARIA violations (preferably no warnings either).
There is a page that includes embedded Vimeo video(s). Included in the code that the iframe brings in is an element with the landmark role "contentinfo", which I am already using in the appropriate place on the website pages. So now I have a violation for duplicate landmark roles.
Is there a good way to solve this? I guess I could use the "old embed code" offered by Vimeo but I'd rather avoid that if at all possible. I've searched all over but can't find any guidelines or best practices for this sort of situation. Maybe I'm not using the right terms?
http://www.w3.org/TR/wai-aria/roles#contentinfo
While the spec does say
"Within any document or application, the author SHOULD mark no more
than one element with the contentinfo role."
it also says
"Note: Because document and application elements can be nested in the
DOM, they may have multiple contentinfo elements as DOM descendants,
assuming each of those is associated with different document nodes,
either by a DOM nesting (e.g., document within document) or by use of
the aria-owns attribute."
So perhaps if your iframe was a document or application, that would satisfy the tool. If not, then the tool might be interpreting the spec incorrectly.
I'm using Scala to produce HTTP, HTML and CSS. I also intend to use Scala to produce Javascript but I haven't got to that stage yet.
What are the advantages of using separate style sheets? CSS offers a form of multiple inheritance by which you can organise the styling of your mark up. However Scala already has its own system of multiple inheritance and other functional languages provide their own powerful methods of problem decomposition and declarative composition. While producing separate style sheets, adds algorithmic complexity and hinders the production of comprehensible clean code.
One of the claimed advantages of separate style sheets is that they use less bandwidth. However I find it difficult to believe that CSS uses significant bandwidth compared to images let alone video. So do separate style sheets give advantages to search engine ranks and site classification? Do they speed up or slow down rendering and layout? Do they help accessibility and user defined style? I would have thought not using separate style sheets might actually speed up delivery in HTTP 1.1 if not in 2.0
Similarly with Head and Body nodes /Tags. Do they serve any advantage to justify the added complexity of producing them programmatically? They don't seem to make any functional difference to what the browser produces.
So the question is how important are separate style sheets and Body and Head nodes to producing optimal web sites? Is it OK to put CSS into the HTML leaf Nodes?
The advantages to using separate stylesheets:
Cachability: no need to re-load the same style over and over again
Smaller size: even with gzip compression, 400 div tags all styled alike will be more bytes on the wire per-page than the page without the styles inlined.
Possibility: Some CSS cannot be expressed in an inline style. For example, any pseudo-element or state selector (:hover, :focus, etc.)
DRY: not applicable if you are building a style tree at compile time to apply to an HTML tree at compile time.
The disadvantages:
Speed: inline styles will be faster to render, since when the browser parses the tag it knows what styles apply.
Locality: inline styles make it easy to see what the element will look like (browser debugging tools make this a moot point)
html / head / body - do I need them?
The general consensus seems to be "yes", principally because you are more likely to run into obscure browser bugs if you don't include them (since the "how to choose what to make a child of which element" algorithm isn't blindingly obvious and some of the corner cases aren't necessarily obvious to the developer).
What is the Document Object Model (DOM)?
I am asking this question because I primarily worked in .NET and I only have limited experience, but I often hear more experienced developers talk about/mention it. I read tutorials online but I am unable to make sense of the whole picture. I know that it is an API!
More specific questions are:
Where is it currently used?
What field(s) of developers use it (ex-.NET developers)?
How relevant is it for all developers in general to understand?
In general terms a DOM is a model for a structured document.
It is a central concept in today's IT and no developer can opt out of DOM. Be it in .net, in HTML, in XML or other domains where it is used.
It applies to all documents (word documents, HTML pages, XML files, etc). In the developer sphere it applies mainly in the HTML and the XML domains with slightly different meanings.
HTML
In the HTML arena, the DOM was introduced to support the revolution called in the late 90ies "dynamic HTML". Before IE4 and Netscape 4.0, HTML documents where not changeable inside the browser (all you had in these remote times to sprite up a web page was "animated GIF" !!!! and HTML was version 3.2).
Therefore dynamically manipulating inside the browser the document sent by the server was a huge revolution and initiated the march towards the attractive web sites we see today.
Javascript had been introduced by Netscape (baptised javascript to surf on the new Java trend, but unrelated) and was supported by both Netscape HTTP servers and Netscape browsers, with Internet Explorer eagerly following the move inside the browser. However When javascript is used to manipulate the content of a document, you need an easy way to designate the part of the document you want to interact with. That's where the DOM comes in. Although HTML 4 is not "well formed", browsers build an internal representation of the page with the "body" element at its top and plenty of html tags below, in a hierarchical organisation (child nodes, parent nodes attributes etc). The DOM is the model underpinning the API that allows to navigate this hierarchy.
Since both Netscape and IE browsers were competing solutions, there was little chance the NS and the IE DOM would converge. The W3C stepped in to allow smaller browser vendors to enter the competition and endeavoured to standardised the DOM. Hence the W3C DOM. All it did was just to introduce another dialect and as everybody knows it took years and two serious competitors to force MS to comply with the standards.
Even though more moderns navigating techniques like JQuery have shorthand notations for the DOM, they internally rely on the DOM.
XML
HTML made obvious the disadvantages of showing leniency towards the "well-formedness" of documents and this ushered a new craze : XML. In the web arena, XML and XSLT were first supported by IE5 and adopted in many more domains than just displaying pages.
To parse XML, in the Java Word mainly, you would develop a SAX parser which is basically a plugin to a SAX engine in which you describe what the engine should do of all the XML events (tags...) it will encounter in the parsed document. Developing a SAX parser is not straightforward but is a low footprint solution.
However you have to develop a specific one for each new document type...
So it was not long before libraries started to appear to parse any document and build an in-memory map of its hierarchy. Because it also had the same concepts of root, parents and children (inherited from SGML through HTML), it was also termed a DOM and the name applies regardless of the library.
Other domains
The concept of DOM is not restricted to or even invented for HTML or XML. A DOM is a general concept applicable to any document, especially those (the vast majority of them do) showing a hierarchical structure in which you need to navigate. You can speak about the DOM of a MS-Word document and there are APIs to navigate these as well.
The DOM is the application programming interface for well-defined HTML and XML structures (per W3C's document). It is used in any place where you interact with the elements of a web page (any element - style, text, attributes, etc). You will hear a lot about the DOM with JavaScript and/or JavaScript libraries, such as jQuery (which, of course, is JavaScript). It is also referenced with Java, ECMAScript, JScript, and VBScript.
If you are programming .NET it is important if you are doing web-based work. If you are doing application programming, it's not as important. The DOM is definitely not a thing of the past - it is used and worked within every day by many developers. With that said, there has been work towards standardization of the DOM across web browsers. (Again, libraries can help hide these differences. This is one reason jQuery is so popular. You don't have to worry about the browser specifics - you just do what you need to do.)
The document I linked to above does a great job of answering all your questions and more. I would highly recommend reading it. If you have more questions, you can also check out the links below:
What is the Document Object Model? (W3C)
Document Object Model (Wikipedia)
I'm really not going to be able to explain it any better than the Wikipedia Article on DOM
But to answer a few of your questions:
Where do we still use it?
Every web browser since the mid-nineties.
Who uses it,
Every web developer since the mid-nineties.
in what technology?
Mostly the web via JavaScript, but pretty much anytime you access XML/HTML programatically you are using some kind of DOM implementation.
How important is it for anyone in .net
carrier? [sic]
Extremely, although you probably use it without even knowing it.
Is this just a thing of the past which
was heavily used but had problems?
If it is then somebody needs to tell John Resig that he has wasted the past 3 years of his life.
When a browser loads an HTML page, its convert it to the Document Object Model (DOM).
The browser's produced HTML DOM, constructs as a tree that consists of all your HTML page element as objects. For example, assuming that you load below HTML page on a browser:
<!DOCTYPE html>
<html>
<head>
<title>website title</title>
</head>
<body>
<p id="js_paragraphId">I'm a paragraph</p>
some website
</body>
</html>
After loading, the browser converts it to:
Some of the ability of scripting languages on HTML DOM consists of:
1- Change all the HTML elements in the page.
2- change all the HTML attributes in the page.
3- Change all the CSS styles on the page.
4- Remove existing HTML elements and attributes.
5- Add new HTML elements and attributes.
6- React to all existing HTML events in the page.
7- create new HTML events on the page.
Let's back to your questions:
1- It currently used in all modern browsers.
2- Front-end developers.
3- All Front-end developers that using scripting languages especially JavaScript.
What is DOM?
The Document Object Model (DOM) is a programming API for HTML and XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. A standard defined by w3 consortium.
Source: http://www.w3.org/TR/WD-DOM/introduction.html