DOM Level 3 and HTMLElement - dom

I'm comparing DOM Level 2 and DOM Level 3 (http://www.w3.org/DOM/DOMTR). I understand DOM Level 2 has different parts such as "Core" and "HTML", and that e.g. the HTMLElement interface is defined in the DOM Level 2 "HTML" part.
Are the HTML-specific definitions part of DOM Level 3 as well? As with Dom Level 2 Core, DOM Level 3 Core does not cover the HTML-specific definitions. However I don't see any DOM Level 3 "HTML" part.

Correct, there is no DOM Level 3 HTML specification. However, DOM Level 2 HTML is being superseded by the HTML5 specification.
For example, the HTMLElement interface is defined here:
http://dev.w3.org/html5/spec/elements.html#htmlelement
Incidentally, DOM 3 Core is also in the process of being superseded by DOM4.
See http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html

Related

Does Svelte in Dev mode auto add class name?

I'm currently looking for a way to capture only svelte components on the DOM tree during development mode. I can see that we I run npm run dev all elements and conponents have the "class='svelte-somerandomID'". Does this only happen in development mode?
Yes, it's only in during development that all elements get a scoping class -- and only with some tools. Actually it's a hack we've added in vite-plugin-svelte to enable more power CSS only HMR.
The classes you're referring to are what Svelte uses to make the CSS in a component apply only to the elements of this component. It adds a class that is unique to the component to all elements that can be affected by the component's CSS, and it also modifies your CSS rules to add the same class to them.
Normally the compiler only adds the scoping class to elements that can actually be targeted by the existing CSS rules in your component. If you really want all the elements in a component to have the scoping class, you can use the same trick that I linked to above: add the following rule to your component's CSS.
* {}
By default the generated class names are a hash of the component's CSS content. But you can also customize them with the cssHash compiler option. Note that vite-plugin-svelte also changes how the class names are generated, to be based on the file name instead of the content.
Since every element in the component would be targeted by this roule, this will cause the Svelte compiler to add the scoping class to all the elements.
If you wanted to automatically generalize this to every element of every component, you may want to do it with a preprocessor (if you need some inspiration, the code I've linked too actually implement this with a preprocessor).
I'm not sure if this is what you really want though. For one thing, only elements get a scoping class: components don't get a scoping class, because components don't have dedicated elements in the DOM (only the ones you may or may not add via the component's markup). The above trick would only give you a mean to select every element of a Svelte component. There might probably be easier or cleaner ways to achieve what you really want. For example, a simple wrapping component, or an action, that would use wrappingElement.querySelectorAll('*') or something...

Dash Python by plot.ly callbacks, and Attributes and Properties in web applications

In Dash, by Plotly helping section in Callbacks https://dash.plotly.com/interactive-graphing it is stated that:
Dash components are described declaratively by a set of attributes. All of these attributes can be updated by callback functions
Using the definition of What is the difference between properties and attributes in HTML?:
Attributes: Attributes are defined by HTML. They initialize DOM properties and then they are done.
Properties: Properties are defined by the DOM (Document Object Model). After DOM has been fully initialized these properties can change.
It is logic and reasonable to say that Dash Callbacks retrieve a specific DOM object by its id, and 'read' its property (not the HTML attribute that initialized it). Example: it is possible to have an Input Callback listening to a graph figure 'hoverData' change property.
If this assumption is true:
So basically dash Callbacks operate after the DOM has been initialized, also again they operate on DOM properties not HTML attributes.
So again if true case this could be clearly stated in documentation which would improve to avoid developers confusing this sometimes not very obvious terms.
Have found an answer, dash callbacks work with DOM Properties which is more accurate than saying HTML attributes.

css clases in template - efficiency

If I create html template element which contains several css class definitions and then clone this template into 1000 instances using owns shadow DOMs, what happens?
I've experimented and I'm not sure if it creates also 1000 identical css class definitions in memory, what would not be efficient.
In Correct way to apply global styles into Shadow DOM is discussed duplicating of styles. Yes, all styles are applied to the elements, thus they are duplicated regardless of whether they are created using template or not. But what about class definitions? Are they shared between template instances or are they duplicated?

how to exclude a css from clientlib in CQ

I am using single clientlib for all the pages in my site. Only for one page, i need to exclude one css file from clientlib.
In this case, Should I create a different clientlib and a different template for that page ?
Or
Is there any other way to do this?
The contents of the clientlibs are determined by the css.txt and js.txt files, and these are just hard-coded lists. The clientlibs are assembled when the application is deployed so modifying their contents at run-time would be problematic.
So you are going to need multiple clientlibs to describe the two different lists of css files. Keep in mind that you can use "embeds", "depends", and "categories" relationships to make referencing them easier. Imagine two simple client libs named A and B - A contains A.css and B contains B.css.
Now imagine I have two web pages: Cats.html and Dogs.html. Cats needs both style sheets, but Dogs only needs B.css. To achieve this, I can give clientlib A a category of just "cats" and clientlib B a category of both "cats" and "dogs".
This way when I get my clientlibs for the Cats page using category "cats", I'll get both style sheets. And when I use category "dogs", I will only get B.css.
There is a good explanation here: http://blogs.adobe.com/experiencedelivers/experience-management/clientlibs-explained-example/

ExtJS: Component VS Element VS other

I've been working with ExtJS for a good few months now, but still don't have a perfectly clear map of what's going on behind the scenes there. I'm just talking about the building blocks of the framework and their most basic functionality.
Ext.Component
Ext.Element
DOM.Element
DOM.Node (?)
CompositeElement (?)
Whatever else (?)
For each of the abovementioned I would like to know:
How to select: by ID, by class, via parent, find (OR children OR query OR select? WTF), siblings, ComponentQuery, DOM-query, CSS-query, etc..
How to manipulate in the tree: create, append, prepend, insert after this sibling, move to that parent, remove, destroy, etc..
How to manipulate on the screen: show, hide, fade, slide, move up, down, change size, etc..
How to identify related to each other: find DOM.Element knowing its Ext.Component, find Ext.Component knowing its DOM.Element, etc..
What is the dependency between them: what happens to the DOM.Element if its Ext.Component is hidden / destroyed / changed / moved, what happens to the Ext.Component if its Ext.Element is hidden / destroyed / changed / moved, etc.
I'm looking for a methodical and logically clear layout of how each is supposed to be used and is expected to behave. I am also hoping that the described functionality can be grouped in corresponding categories, e.g. would be nice to see complement traversing methods .up() and .down() next to each other, rather than alphabetically pages apart. Of course links and examples (which the official documentation lacks so badly) are also welcome!
You can find out a whole lot about the building blocks of ExtJS (known as Ext Core) from the manual for this: http://docs.sencha.com/core/manual/. I will try to add some knowledge and highlight some key points, but you should definitely read through that for a very informative overview.
Ext.Component
The building block for the OOP paradigm within ExtJS. Essentially, this is an Object that contains inherited functionality to serve as the basis for a specialized component that will be transformed by the framework into DOM elements that are shown as HTML.
The Sencha documentation is excellent for this. Here are a couple good places to start:
http://docs.sencha.com/extjs/4.2.1/#!/guide/layouts_and_containers
http://docs.sencha.com/extjs/4.2.1/#!/guide/components
Ext.Element vs DOM Element
As an JavaScript develop knows, a DOM element is just a JS object that represents a tag in the document's HTML. Essentially, Ext.Element is a wrapper object for a DOM element that allows for ExtJS to manipulate the object. Any DOM element on the page can be wrapped as an Ext.Element to allow for this additional functionality.
For example, take this HTML tag:
<div id="myDiv">My content</div>
You can access this using
var el = document.getElementById('myDiv')
and use the basic, built-in JavaScript DOM functionality on el. You could also access this using
var el = Ext.get('myDiv')
and have a whole additional set of functionality available to apply to that element using the ExtJS library
The Sencha docs are also excellent for this. See all the available functionality for Ext.Element here: http://docs.sencha.com/extjs/4.2.1/#!/api/Ext.dom.Element
Misc
You can get an Ext.Element from a component using the getEl() method:
var myComponent = Ext.create('Ext.Component', { html: 'my component' });
var el = myComponent.getEl();
You would rarely need to go the other way, to determine a component from a DOM element. There isn't much of a use case there unless you are really hacking something. A major reason for using a framework like ExtJS is to prevent needing to do something like this; if should develop entirely within the JavaScript, you should be able to avoid having a reference to a DOM element where you need to get its containing ExtJS component.
Niklas answered pretty well about how to select components and elements. The only things I would really add is that you can use up() and down() to select relative to a component. In this way, you should use itemId on components rather than the global identifier id (using id can cause difficult-to-debug errors if you are reusing components with the same ID).
Also, to add to Niklas's answer about showing/hiding components, the framework does indeed add some CSS to the component's element, depending on what the hideMode for the component is. Learn more about that property here: http://docs.sencha.com/extjs/4.2.1/#!/api/Ext.AbstractComponent-cfg-hideMode
An excellent way to learn more is to look through all of the examples that come packaged with the framework. Open the examples in your browser, then look through the code to find out how things are done. You will find it way easier to learn this way, rather than reading it on paper or a website. Nothing beats experience when it comes to learning something new.
How to select: by ID, by class, via parent, find (OR children OR query OR select? WTF), siblings, ComponentQuery, DOM-query, CSS-query, etc..
Ext.ComponentQuery.query("*") // get all
Ext.ComponentQuery.query("button") // all buttons
Ext.ComponentQuery.query("#myid") // all controls / components myid
Ext.ComponentQuery.query("#myid", rootelement) // all controls / components myid with rootelement
Ext.ComponentQuery.query("#myid,button") // all buttons or controls / components myid
How to manipulate in the tree: create, append, prepend, insert after this sibling, move to that parent, remove, destroy, etc..
Adding button to a View:
Ext.ComponentQuery.query("#viewId")[0].add(new Ext.Button({ text: 'test'}));
There is also insert, remove and so on depending on the control you are querying.
How to manipulate on the screen: show, hide, fade, slide, move up, down, change size, etc..
Ext.ComponentQuery.query("button").forEach(function(button){ button.hide(); }) // hide all buttons
There is also show, disable, enable and so on depending on the control you are querying.
How to identify related to each other: find DOM.Element knowing its Ext.Component, find Ext.Component knowing its DOM.Element, etc..
Finding Ext.Component knowing its Dom.Element is pretty easy, you just take the ID from the DOM element and use Ext.ComponentQuery.query("#id").
There is also Ext.select('#id') for getting the object from an ID.
With the element property you can get the DOM:
var dom = Ext.ComponentQuery.query("button")[0].element.dom // Getting the DOM from the first button
var dom2 = component.element.dom // does also work as long as component is a valid sencha touch component
What is the dependency between them: what happens to the DOM.Element if its Ext.Component is hidden / destroyed / changed / moved, what happens to the Ext.Component if its Ext.Element is hidden / destroyed / changed / moved, etc.
I think, I'm not sure, that if you call .hide for instance there will be some CSS applied to the DOM for example: display: none. Internally they can use some framework like jQuery for that or the old school version document.getElementById('id').css and so one. If you call .show, it may change to display: block or whatever type it was before(this could be saved in the Sencha Touch class).
I don't know what happens if the DOM element gets destroyed. Probably the element too and then the garbage collector has some work to do.
If there are any more questions / something was unclear or not enough, don't hesitate to ask.
An attempt to answer the question myself.
Since there is no TABLE markup support on this website, I put my answer in this shared Spreadsheet. Note the comments on mouse rollover.
It's just a pattern for now. It needs work to get more legible and complete. Feel free to comment, or ask me if you would like to edit it.