# reasoning_with_style__14825ba2.pdf

Reasoning with Style

Mart ı Bosch

Universitat Polit ecnica de Catalunya Pierre Genev es

CNRS, LIG Nabil Laya ıda

The Cascading Style Sheets (CSS) language constitutes a key component of web applications. It offers a series of sophisticated features to stylize web pages. Its apparent simplicity and power are however counter-balanced by the difficulty of debugging and maintaining style sheets, tasks for which developers still lack appropriate tools. In particular, significant portions of CSS code become either useless or redundant, and tend to accumulate over time. The situation becomes even worse as more complex features are added to the CSS language (e.g. CSS3 powerful selectors). A direct consequence is a waste of CPU that is required to display web pages, as well as the significant amount of useless traffic at web scale. Style sheets are designed to operate on a set of documents (possibly generated). However, existing techniques consist in syntax validators, optimizers and runtime debuggers that operate in one particular document instance. As such, they do not provide guarantees concerning all web pages in CSS refactoring, such as preservation of the formatting. This is partly because they are essentially syntactic and do not take advantage of CSS semantics to detect redundancies. We propose a set of automated refactoring techniques aimed at removing redundant and inaccessible declarations and rules, without affecting the layout of any document to which the style sheet is applied. We implemented a prototype that has been extensively tested with popular web sites (such as Google Sites, CNN, Apple, etc.). We show that significant size reduction can be obtained while preserving the code readability and improving maintainability.

1 Introduction

Cascading Style Sheets (CSS) [Consortium, 2014; Lie, 2005] is a style sheet language used to format documents written in markup languages, and nowadays it is widely used to style web pages. To suit the current context, where so much attention is paid to the user experience in different kinds of devices, it includes a series of sophisticated features that offer a very wide range of possibilities to designers and developers. Despite its widespread use and increasingly important role, CSS received very little attention from the research community [Quint and Vatton, 2007; Marden and Munson, 1999] with the notable exceptions of [Genev es et al., 2012;

Mesbah and Mirshokraie, 2012]. The simplicity of CSS syntax may be misleading as it hides the complexity of its most advanced aspects. For this reason, developers increasingly rely on frameworks that automatically generate CSS files. This often results in a code that is very hard to maintain. This also leads to redundant declarations and inaccessible selectors, that unnecessarily increase resources required to transfer the CSS files (and therefore web traffic at a global scale) and to process the page layout. Previous studies [Meyerovich and Bodik, 2010] showed that the visual layout of web pages consumes 40 70% of the processing time of the browser. Simplifying CSS code is essential in reducing this cost. Current syntax optimizers1 perform only syntactic analyses, and are unaware of the CSS semantics. Therefore, they can only achieve a fraction of the potential optimizations. The standard CSS development practice involves the use of empirical methods such as runtime debuggers. While these tools are useful in testing, they depend strongly on the document instance on which the style sheet is applied. However, as style sheets usually apply to a wider set of documents, modifications achieved on a particular instance might undesirably alter the presentation of other documents. On the other hand, CSS code very often comes from different sources, such as external files, the HTML s style element, or inline styles set directly as attributes on specific elements. This makes it hard to spot the origin of bugs, and incurs significant debugging costs. The tool we propose is intended to remove redundant code, clean and refactor CSS files, lessening the reliance on debuggers as well as reducing file s sizes. Our tool involves automated analysis of the style sheet semantics for performing size reductions which are not achievable by existing (syntactic) compressors.

Contributions and Outline We recall the main concepts of CSS in Section 2. We propose automated refactoring techniques in Section 3 that aim at removing redundant and inaccessible CSS declarations and rules, while preserving the layout of documents to which the style sheet is applied2. We implemented a prototype described in Section 4. We report on experimental results with CSS of popular web sites (such as Google Sites, CNN, Apple, etc.) in Section 5. We show

1For example: cleancss.com, codebeautifier.com, csslint.net, etc. 2Work partially supported by ANR TYPEX ANR-11-BS02-00.

Proceedings of the Twenty-Fourth International Joint Conference on Artificial Intelligence (IJCAI 2015)

that we obtain significant size reductions for these sites that represent a considerable fraction of web traffic.

2 The CSS Language Cascading Style Sheets play nowadays a key role in the web infrastructure and in enhancing the user experience. Besides web developers, the simplicity of its syntax has attracted also graphical and web designers. CSS permits separating the content from presentation and a few rules are capable of producing impressively fancy presentations. A style sheet C can be seen as a sequence of rules, where each rule R consists of a selector S, and a set of declarations called declaration blocks. Selectors identify the set of elements that are styled by the declarations di. Each declaration di is a pair of a property pi and its associated value vi, that define how the elements selected by S will look like in the browser.

2.1 Selectors CSS selectors decide which elements will be styled by the rules declarations. The selectors language is very expressive and permits matching elements based on the elements structure and attributes, as well as grouping selectors that share the same declarations. Selectors Level 3 [C elik et al., 2011] also includes a series of advanced features that empower CSS styling capabilities while inevitably making it more complex. An efficient use of selectors is one of the key aspects towards the conception of maintainable CSS code.

2.2 Specificity When several rules apply to a given element, CSS prioritizes the declarations that have the !important specifier. In case of equality, CSS picks the declaration whose selector has a highest specificity. The specificity of a selector is represented by a four integer vector, whose components are, from most to less important, determined as: (1) 1 if the property is declared under the style attribute, 0 otherwise, (2) the number of references to the id attribute with the # symbol, (3) the number of class selectors, attribute selectors and pseudo-classes, and (4) the number of element type selectors and pseudo-elements. If the selectors have the same specificity, the latter rule in the syntactic order gets precedence.

2.3 Media Rules A media rule starts by @media followed by a condition called media query. This defines a block in which we can add a set of CSS rules that only apply when the media query is satisfied. The media queries define the style sheet target according to expressions concerning devices features, as for example the dimensions. Such features are key to define how web pages look like on mobile devices. To adjust more precisely the style sheet scope, media queries might use several logical operators to connect different expressions. It is important to be aware that media rules do not alter the specificity.

3 CSS Refactoring Techniques In this section, we introduce a series of refactoring techniques capable of identifying and deleting unaccessible declarations and combine rules in a way such that the same rendering semantics is preserved with lighter CSS files. These

techniques do not require any information other than the style sheet itself, regardless of which instance is under consideration. For this purpose, our methods rely on the semantics of the CSS components described previously. In particular, our method aim at analysing and leveraging the fact that in CSS, rules use selectors that match the set of elements that are styled by the rule s declarations. Our main method consists in the detection of semantic relations between CSS selectors. When some of these relations are detected, further analysis of some CSS aspects might reveal that some declarations are in fact unnecessary and can be deleted.

3.1 Deleting redundant declarations

In the context of this paper, we will state a CSS declaration as redundant if (1) it is always masked by another declaration, or (2) it is verbose as the styling that it provides is already provided by some other declaration.

Masked declarations A declaration da is always inactive iff it is masked by some other declaration db concerning the same CSS property. In order to mask da, db must apply to at least the same set of elements as da, and this is why relations between the selectors under which da and db are stated become crucial: selectors must either hold an equivalence or a containment relation.

Listing 1: Example of masked declaration

1 li.foo { text-indent: none; 2 color: blue; 3 font-weight: bold } 4 li[class= foo ] { text-indent: 10px; 5 color: blue }

In Listing 1 we have two rules with equivalent selectors: li.foo and li[class= foo ] both select an li element with the class attribute set to foo . They just use different syntax to achieve the same semantics. Any element matched by the first rule will also be matched by the second one and viceversa, and as both rules have declarations concerning the properties color and text-indent, CSS specificity will decide which values will apply. In Listing 1, both selectors have the same specificity, so the declarations under the latter one li[class= foo ] will have preference. Consequently, for these conflicting declarations, the values from li[class= foo ] will apply, and the ones from li.foo will be always inactive (masked). By deleting those declarations we achieve a lighter code with the same rendering semantics: Listing 2.

Listing 2: Code after deleting the masked declarations

1 li.foo { font-weight: bold } 2 li[class= foo ] { text-indent: 10px; 3 color: blue }

Consider we replace li[class= foo ] by li[class] in Listing 1. The selector li[class] matches any li element with the class attribute set (to any value). Notice then that li.foo li[class] ,

given that any li element with the class attribute set to foo does indeed have the class attribute set, but not all the li elements with the class attribute defined need to have it set to the value foo . Observe then that the set of elements pointed by li.foo will also be pointed by li[class] , so the declarations concerning the properties color and text-indent set under li.foo will be completely masked by those set under li[class] , as li[class] gets preference as it has the same specificity but is stated after li.foo . Let us note by db p the set of declarations concerning a CSS property that is stated under both selectors Sb and Sp. When there are two rules with selectors such that Sb Sp and Sp has preference over Sb, the deletion of declarations that are masked is carried automatically by Procedure 1:

Procedure 1: Sb Sp with Sp preferred over Sb

foreach di in db p do

delete di from Sb end

Verbose declarations A CSS declaration might be active in some occasions and yet not provide any additional styling. In the context of this paper, they will be noted as verbose declarations. To understand how we might find them, consider Listing 3.

Listing 3: Example of verbose declarations

1 div div > a { font-size: 14px; 2 text-decoration: none } 3 div a { font-size: 14px; 4 text-decoration: underline }

There are two rules whose selectors hold a containment relation div div > a div a . Note that any a element with a div father and another div ancestor also matches the pattern of a a element with a div ancestor. In this case div div > a has highest specificity than div a , so when their declarations conflict, the ones stated under div div > a dominate. Consequently for an element selected by the subset (and implicitly by the superset as well), the value for text-decoration will be none. Nevertheless, for the same element, font-size is set to 14px by both selectors, so although the value is pulled from the subset, it would always be pulled from the superset as well, and thus the declaration font-size:14px under div div > a is verbose and can be deleted, yielding Listing 4.

Listing 4: Code after deleting the verbose declarations

1 div div > a { text-decoration: none } 2 div a { font-size: 14px; 3 text-decoration: underline }

This refactoring can be automatically performed by Procedure 2. Such procedure can only be applied to a subset in strict containment, as in the case of equivalence Procedure 1 would apply due to the symmetric nature of the relation.

Procedure 2: Sb Sp with Sb preferred over Sp

foreach di in db p do

if di sets the same value under both Sb and Sp then

delete di from Sb end end

3.2 Relations and Media Rules

Media queries may also cause certain inconsistencies. For example, observe in Listing 5 that a device that satisfies the first media query will always satisfy the second one as well. And considering that media rules do not alter selector s specificity, in this case color: red will never be applied. Note that, if we reverse the order of the media rules, color: blue will be active for devices wider than 800px but smaller than 1000px, so the color of the div elements would be blue. One can reasonably guess that this was the behaviour that the developer intended.

Listing 5: Relations and Media Rules

1 @media (min-width: 1000px) { 2 div { color: red } } 3 @media (min-width: 800px) { 4 div { color: blue } }

These inconsistencies can be detected too. Given two media rules, they will either hold: (a) no relation (which will be the case most of the time), (b) a containment relation, like in Listing 5 or (c) an equivalence relation. In order to perform the refactoring procedures proposed in Section 3.1 in presence of media rules, we have to see how selectors relations change according to their respective media context, which can happen in two ways: 1. Destruction of relations consider a style sheet with Sa = div p under a media query m Qa = all and Sb = p under m Qb = tv . Note that div p p , but div p applies in all media contexts whereas p is only active for tv media types. So whenever we are not under a tv device, div p might point to elements that p would not, and thus it breaks the nature of the containment relation, and prevents our tool from performing the refactorings proposed in Section 3.1, which become no longer safe to achieve. 2. Equivalence transformed into containment consider again Listing 5. We have two identical selectors Sa, Sb = div , in two different media contexts, m Qa = (min-width: 1000px) and m Qb = (min-widith: 800px) , being true that m Qa m Qb. Under these circumstances, any device satisfying m Qa will also satisfy m Qb, but not the other way around. So whenever Sa selects all the div elements, Sb will do too, but not conversely. In short, an equivalence relation is turned into containment. After both cases are considered, the refactoring procedures from Section 3.1 can be performed in presence of media rules.

3.3 Deleting Empty Rules

The procedures above are meant to delete declarations from CSS rules. Applying such procedures might result in an empty rule containing a selector with no declarations. This rule does select a set of elements but does not define any styling for them. Consequently, it is safely deleted.

3.4 Merging Rules with Equivalent Selectors

Given two equivalent selectors Sa and Sb, merging their respective rules Ra and Rb can reduce the style sheet s size. By merging Ra and Rb we mean the following: as Sa and Sb affect the same set of elements, we group both rules declarations. We keep Sa and move all the declarations from Rb to Ra. If any declaration concerns the same property with different values set under Ra and Rb, Section 3.1 already takes care of it. To exemplify the procedure, consider Listing 6.

Listing 6: Merging rules with equivalent selectors

1 a#nav { padding: 0px; 2 height: 20px } 3 a[id= nav ] { margin: 5px } 4 p a[id= nav ] { margin: 10px }

We have two equivalent selectors a#nav a[id= nav ] , so we keep the rule with a#nav , and move margin: 5px from a[id= nav ] to a#nav . Instead of 2 rules with 2 and 1 declarations each, after this refactoring we have 1 rule with 3 declarations. However, we cannot perform this refactoring as it does not preserve the style sheet s semantics. The reason is because selectors confer its specificity to the declarations that they encapsulate. For example, in Listing 6, when we move margin: 5px from a[id= nav ] to a#nav , for an element pointed by p a[id= nav ] , the declaration margin: 10px will always be inactive as p a[id= nav ] a#nav , and a#nav will confer its higher specificity to its declaration margin: 5px , and so it would override margin: 10px . If we do not refactor Listing 6, margin: 5px has the specificity from its selector a[id= nav ] , which is lower than the one from p a[id= nav ] . Therefore, for the set of elements matched by p a[id= nav ] , margin will be 10px.

Applicability of the Procedure To safely merge a pair of rules Ra and Rb with equivalent selectors Sa Sb, we need to guarantee that there is no selector Sc or Sd in the style sheet such that: (i) Sc Sa with Sc preferred over Sa, and Sb preferred over Sc or (ii) Sd Sa with Sd preferred over Sa, and Sb preferred over Sd. Note that as Sa Sb, the relation Sc Sa already implies that Sc Sb, and the same applies to Sd. More generally, a pair of rules with equivalent selectors Sa Sb might be merged if all the selectors that hold a containment relationship with them, are either more specific than both Sa and Sb, or are less specific than both Sa and Sb. Observe that in Listing 6, the subset p a[id= nav ] is more specific than a[id= nav ] but less specific than a#nav , and that is why the rules cannot be merged. However, if a rule Rx with a selector Sx fulfilling the conditions of (i) or (ii) was found, the rules Ra and Rb might

still be merged only if the declarations we move among Ra and Rb do not concern any of the properties declared under Rx. In Listing 6, we can safely move padding: 0px and height: 20px from the rule with the selector a#nav to the one with a[id= nav ] , and delete the resulting empty rule a#nav { } . So after merging a#nav and a[id= nav ] while preserving the semantics, we obtain Listing 7. In realistic style sheets, a much larger set of rules need to be considered in order to determine if this refactoring is valid or not.

Listing 7: After merging rules the right way

1 a[id= nav ] { margin: 5px; 2 padding: 0px; 3 height: 20px } 4 p a[id= nav ] { margin: 10px }

4 Implementation techniques 4.1 Modeling & Analysis of Single Selectors To detect relations between selectors, we first translate selectors in a logic: each selector Si is associated with a logical formula F(Si), and then we issue external calls to a logical satisfiability solver such as the one of [Genev es et al., 2007; Genev es et al., 2015] to check for the existence of relations between the formulas. For instance, the validity of a containment relation Si Sj is checked by testing for the unsatisfiability of the negation of the logical implication F(Si) = F(Sj).

4.2 Grouped Selectors A grouped selector is a list of n > 1 single selectors, separated by a comma character. The translation of a grouped selector Sg intro tree logic requires the translation of each one of the n single selectors. The comma character plays the role of a logical or between the different single selectors that compose the group, so the logical disjunction operator | will be used to connect the single selectors translations, capturing this way the semantics of the grouped selector. Given a grouped selector Sg, composed by n single selectors sg,i, we have: F(Sg) = F(sg,1) | F(sg,2) | . . . | F(sg,n)

Specificity and grouped selectors Given a pair of single selectors, to determine which one gets precedence, we calculate their specificity vectors, and compare their components. Nevertheless, specificity cannot be determined for grouped selectors. Instead, our tool includes an advanced mechanism to determine, if possible, which selector will get precedence when grouped selectors are present. Sometimes this cannot be determined, and our tool does not refactor the code as it might not preserve its semantics.

4.3 Traversal of Selectors Given a style sheet with N rules, there will be N selectors Si where i = 1, 2, . . . , N. To detect all the possible relations between selectors, each Si has to be tested for logical inclusion against the remaining N 1 selectors. This adds up to a total of N (N 1) tests, which for style sheets with more than 1000 rules results in millions of tests. Since logical tests

are the heaviest computation of our tool, several mechanisms can be used to avoid such explosion: 1. If two selectors point to elements with different names, they will always represent disjoint sets 2. If a selector S1 refers to one or more attributes that S2 does not, S1 will never contain S2 3. Given a pair of selectors such that S1 S2, and a third selector S3, if (a) S3 S1, (b) S3 S1 or (c) S3 S1, then (a) S3 S2, (b) S3 S2 or (c) S3 S2 due to the transitivity of equivalence and containment binary relations

5 Experimental Results

We now report on the experimental evaluation of our refactoring methods with real-world style sheets used in some of the most popular web sites.

5.1 Analysis of Single CSS Files We have extracted in Table 1 the largest CSS file used in 20 different websites corresponding to various web applications types and having different complexity levels. For the sake of brevity, an identifier (integer) is used to identify each of them. The number of CSS rules is shown in this table. This number gives a clear idea of the style sheet s size and constitutes a relevant metric for the techniques described in this paper. The file sizes range from 10 to 320 Kilobytes.

ID Web # CSS Rules ID Web # CSS Rules 1 ACM Digital Lib. 102 11 Google Sites4 1676 2 Aerolineas Argentinas 1284 12 IJCAI-15 384 3 Apple 784 13 Lamborghini 1472 4 Argentina Travel 651 14 Microsoft 702 5 Clarin 1188 15 Opera 708 6 CNN 2738 16 Pay Pal 1089 7 Coursera 3690 17 Salesforce 1158 8 Ebay 1573 18 Shell 1111 9 Facebook 2757 19 Univ. of Cambridge 845 10 Foundation3 800 20 You Tube 1841

Table 1: Dataset for the experiments

In the remaining part of this Section, whenever global averages of percentages are calculated, we take the total deletions in all files and compare it to the total files size. Our tool prototype does not yet support all CSS3 selectors5, so the percentages are determined relative to the part of the style sheet that our prototype supports. For each file, the size reduction achieved by applying all the refactoring techniques from Section 3 is shown in Figure 1. On average, the style sheets sizes have been reduced a 7.75 %. A 7.79 % of the declarations have been safely deleted, modifying a 13.66 % of the rules and leaving a 4.71 % of the total style sheet s rules empty. Deleting redundant declarations with the procedures from Section 3.1 contributes to a 60.22 % of the total size reduction, whereas deleting the rules that became empty (as proposed in Section 3.3), contributes to a 31.70 %. Merging rules

3ZURB Foundation framework s default template 4Google Sites default template 5As of February 2015, 69.46 % of selectors in the dataset of Table 1 are supported.

11.69 8.63 11.24 6.04 6.48 10.63 9.7 4.32 1.55 4.34 17.83 4.74 12.58 4.17 4.74 5.68 5.36 6.43 8.37 1.41

% of Deleted Bytes

Figure 1: % of deleted bytes for each data set entry

as explained in Section 3.4 only contributes by an 8.08 % size reduction (in bytes). Media Rules are considered in this analysis, but they are not a procedure itself but transform selectors relations, as explained in Section 3.2. Besides the averages, the percentages of file size reduction in bytes vary dramatically among the style sheets, and so does the contribution of the different refactorings proposed in Section 3. This shows that the inconsistencies found on the style sheets depend mostly on the developers, which suffer from the lack of tools like the one that we propose.

5.2 Style Sheets with Multiple Files Modern web applications often use several CSS files to define their presentation. Each file might correspond to the styling of distinct sections of the application, different parts of the same page, or some groupings which resembles libraries. Regardless of the specific instances of the HTML involved, our tool can achieve the refactoring procedures across several CSS files. The information needed for the analysis is extracted from HTML documents: it consists in exploring the !DOCTYPE declaration, and the link elements that are under the head element. For each link element with the attribute rel="stylesheet", we retrieve the CSS file referenced by the href attribute, and if the media attribute is set, we extract its value. Such a value corresponds to a media query setting the style sheet s media type. If the media attribute is not set, then the style sheet s media type takes the default value as described in the specification: all in HTML5 or screen in HTML 4 and XHTML 1, which is why we need to extract !DOCTYPE specification. To analyze style sheets with several files, we have retained the web sites of our dataset whose main HTML page has more than one CSS file referenced in link elements. This new dataset is shown in Table 2, as well as the extra information extracted for this analysis and the total number of rules. One of the many CSS subtleties is that declarations from one file might become redundant because of declarations stated in some other files. To see how this might affect the results of our refactoring procedures, in this section, we perform two experiments for each of the items listed in Table 2. The first experiment consists in analyzing all of the item s CSS files separately, as if they were used in isolation and

ID Web Doc Type # CSS Files Default Media # CSS Rules 9 Facebook HTML5 5 all 3543 11 Google Sites4 XHTML 1 6 screen 2046 12 IJCAI-15 XHTML 1 14 screen 1170 15 Opera HTML5 2 all 890 16 Pay Pal HTML5 3 all 1186 18 Shell HTML5 6 all 1551 20 You Tube HTML5 4 all 3615

Table 2: Dataset for the experiments.

without interaction between them. For the second experiment, we use the information extracted from the link elements to emulate the global compounded style sheet that the browser will effectively use, and we then apply our refactoring over it. The refactoring that our tool performs in this second experiment does not alter the presentation of any HTML instance, as long as the instance: (1) has the same !DOCTYPE declaration as the site s default (listed in Table 2), and (2) includes at least the same references to external CSS files (the link elements under head). If (1) or (2) are not satisfied, then our tool does not guarantee the semantic preservation of the presentation. The average time spent for the overall static analysis of a dataset entry is 91 s, with an average time of 49 ms spent in each logical solver test. For each item in Table 2, Figure 2 shows the percentages of deleted bytes for the two experiments. We can observe that for every item there exists some interaction between the different files, since more bytes are always deleted in the second experiment. Overall, Figure 2 shows that, in the setting of style sheets using several files, rules from different files tend to collide, and in some cases this results in many more inaccessible and redundant declarations.

Separated Together

Figure 2: % of deleted bytes on multiple-file style sheets.

6 Related Work

Little research effort has been dedicated to study the CSS language and fewer have been dedicated to the quality of widely deployed style sheets. The work found in [Liang et al., 2013] explores a visual approach to track the effect of source code modifications. This approach can be complementary to existing runtime debuggers available in current browsers

[Mozilla, 2014; Google, 2014; Opera, 2014]. [Keller and Nussbaumer, 2009; 2010; Benson, 2013; Sinha and Karim, 2013] focus on the reusability of CSS for different platforms, whereas [Benson and Karger, 2013] introduces a formalism to better separate CSS structural and styling components. The work found in [Genev es et al., 2012] does not consider CSS refactoring nor their compression, but it introduces a translation of CSS selectors into a tree logic for the purpose of detecting bugs. Our paper relies on an generalisation and extension of such a translation for the part concerned with the detection of relations between selectors. Closer to our work we find [Mesbah and Mirshokraie, 2012] that proposed an analysis whose purpose is to dynamically detect unused declarations. The most closely related research work can be found in [Mazinanian et al., 2014]. The authors present layout-preserving refactoring techniques for CSS based on the detection of rules with very similar declaration blocks. Selectors are grouped and shorthands are used for recombining those rules. Their tool is tested with a large dataset and also obtains interesting size reductions. A fundamental difference with our approach is that their analysis is incomplete and conducted at runtime on a particular instance. In contrast, our static analysis technique needs to be performed only once and the size reduction is observed every time a page is fetched by a different user. Furthermore, the refactoring achieved by [Mazinanian et al., 2014] can be used alongside those obtained in the present paper, as our tool is capable of actually deleting declarations rather than recombining or compressing them. One promising research work would consist in investigating a technique combining both static and dynamic analyses.

7 Conclusion and Perspectives

We present techniques and a tool capable of automatically refactoring CSS files with the aim of reducing the sizes of style sheets, while preserving their rendering semantics. In contrast with the existing tools which are mostly dynamic and operate with a particular document instance, our techniques are based on the static analysis of semantic relations between CSS selectors and media queries. Our refactoring applies on a given style sheet, independently of any particular document instance, and reduces the style sheet size once for all. Our technique can be used in combination with existing syntactic optimisers since it performs size reductions that the latter cannot do. Experimental results show that our approach is capable of reducing significantly the size of CSS files of some of the most popular and sophisticated web sites. For the CSS files tested separately, our preliminary prototype has achieved an average size reduction of 7.75 %, with a maximum of 17.83 %. Furthermore, we showed that, with very little information about the documents that use a style sheet, the size reduction can increase up to 30 %. One promising perspective for further work consists in extending the analyses by taking into account constraints, such as DTDs or schemas (like those defined in e.g. the XHTML Mobile Profile for mobile phones). The knowledge of additional structural constraints would certainly be beneficial in detecting even more refactoring opportunities.

References [Benson and Karger, 2013] Edward Benson and David R. Karger. Cascading tree sheets and recombinant HTML: better encapsulation and retargeting of web content. In WWW 13, pages 107 118, 2013. [Benson, 2013] Edward Benson. Mockup driven web development. In Proceedings of the 22nd International Conference on World Wide Web Companion, WWW 13 Companion, pages 337 342, 2013. [C elik et al., 2011] Tantek C elik, Elika J. Etemad, Daniel Glazman, Ian Hickson, Peter Linss, and John Williams. Selectors level 3. W3C recommendation, World Wide Web Consortium, September 2011. [Consortium, 2014] World Wide Web Consortium. CSS specifications, November 2014. http://www.w3.org/Style/CSS/current-work. [Genev es et al., 2007] Pierre Genev es, Nabil Laya ıda, and Alan Schmitt. Efficient static analysis of XML paths and types. In PLDI 07, pages 342 351, 2007. [Genev es et al., 2012] Pierre Genev es, Nabil Laya ıda, and Vincent Quint. On the analysis of cascading style sheets. In WWW 12, pages 809 818, 2012. [Genev es et al., 2015] Pierre Genev es, Nabil Laya ıda, Alan Schmitt, and Nils Gesbert. Efficiently Deciding µCalculus with Converse over Finite Trees. ACM Transactions on Computational Logic, 16(2), 2015. [Google, 2014] Google. Chrome Developer Tools, November 2014. https://developer.chrome.com/devtools/. [Keller and Nussbaumer, 2009] Matthias Keller and Martin Nussbaumer. Cascading style sheets: a novel approach towards productive styling with today s standards. In Proceedings of the 18th international conference on World wide web, WWW 09, pages 1161 1162, 2009. [Keller and Nussbaumer, 2010] Matthias Keller and Martin Nussbaumer. CSS code quality: A metric for abstractness. In Seventh International Conference on the Quality of Information and Communications Technology (QUATIC), pages 116 121, October 2010. [Liang et al., 2013] Hsiang-Sheng Liang, Kuan-Hung Kuo, Po-Wei Lee, Yu-Chien Chan, Yu-Chin Lin, and Mike Y. Chen. See SS: Seeing what i broke visualizing change impact of cascading style sheets (CSS). In UIST 13, pages 353 356, 2013. [Lie, 2005] Hkon Wium Lie. Cascading style sheets. Phd thesis, Faculty of Mathematics and Natural Sciences, University of Oslo, 2005. [Marden and Munson, 1999] Philip M. Marden and Ethan V. Munson. Today s style sheet standards: the great vision blinded. Computer, 32(11):123 125, nov 1999. [Mazinanian et al., 2014] Davood Mazinanian, Nikolaos Tsantalis, and Ali Mesbah. Discovering refactoring opportunities in cascading style sheets. In Proceedings of the ACM SIGSOFT International Symposium on the Foundations of Software Engineering (FSE), page 11 pages, 2014.

[Mesbah and Mirshokraie, 2012] Ali Mesbah and Shabnam Mirshokraie. Automated analysis of CSS rules to support style maintenance. In ICSE 12, pages 408 418, 2012. [Meyerovich and Bodik, 2010] Leo A. Meyerovich and Rastislav Bodik. Fast and parallel webpage layout. In Proceedings of the 19th International Conference on World Wide Web, WWW 10, pages 711 720, 2010. [Mozilla, 2014] Mozilla. Firebug, November 2014. https://getfirebug.com/. [Opera, 2014] Opera. Opera Dragonfly, November 2014. http://www.opera.com/dragonfly/. [Quint and Vatton, 2007] Vincent Quint and Ir ene Vatton. Editing with style. In Proceedings of the 2007 ACM symposium on Document engineering, Doc Eng 07, pages 151 160, 2007. [Sinha and Karim, 2013] Nishant Sinha and Rezwana Karim. Compiling mockups to flexible uis. In Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering, pages 312 322, 2013.